17장. AWS 기반 AI 서비스 구성

1. 클라우드 AI를 실제 서비스 구조로 옮기기

앞 장에서는 클라우드 AI를 쓰는 이유를 살펴보았다.

클라우드 AI를 사용하면 모델을 직접 설치하거나 GPU 서버를 운영하지 않아도 된다.
API를 호출하는 방식으로 요약, 분류, 번역, 문서 검색, 코드 분석 같은 기능을 빠르게 만들 수 있다.

이제 한 단계 더 들어가 보자.

이번 장에서는 AWS를 기준으로 AI 서비스를 어떻게 구성할 수 있는지 살펴본다.

AWS에서 AI 기능을 만들 때 사용할 수 있는 대표적인 구성 요소는 다음과 같다.

- Amazon Bedrock
- AWS Lambda
- Amazon S3
- Amazon API Gateway
- Amazon CloudWatch
- AWS IAM

이 장의 목적은 AWS의 모든 AI 서비스를 깊게 설명하는 것이 아니다.
초보 개발자가 AWS 위에서 AI 기능을 만들 때 전체 구성이 어떻게 연결되는지 이해하는 것이 목적이다.

예를 들어 다음과 같은 기능을 만든다고 해보자.

관리자 페이지에서 고객 문의를 선택한다.
→ "AI 요약" 버튼을 누른다.
→ 백엔드가 AWS 기반 AI 기능을 호출한다.
→ AI가 문의 내용을 요약한다.
→ 요약 결과를 관리자 화면에 표시한다.

또는 사내 문서 검색 챗봇을 만든다고 해보자.

사내 문서를 S3에 업로드한다.
→ 문서를 임베딩하여 검색 가능한 형태로 저장한다.
→ 사용자가 질문한다.
→ 관련 문서를 검색한다.
→ Bedrock 모델이 문서 기반 답변을 생성한다.

이런 구조를 만들 때 AWS의 각 서비스가 어떤 역할을 하는지 이해해야 한다.

2. AWS 기반 AI 서비스의 기본 구조

AWS 위에서 AI 기능을 구성할 때 가장 단순한 흐름은 다음과 같다.

사용자
→ 프론트엔드
→ API Gateway
→ Lambda
→ Amazon Bedrock
→ Lambda
→ API Gateway
→ 프론트엔드
→ 사용자

여기서 각 서비스의 역할은 다음과 같다.

간단한 고객 문의 요약 기능이라면 다음처럼 동작할 수 있다.

1. 관리자가 고객 문의 요약 버튼을 누른다.
2. 프론트엔드가 API Gateway로 요청을 보낸다.
3. API Gateway가 Lambda를 호출한다.
4. Lambda가 문의 내용을 가져오고 프롬프트를 만든다.
5. Lambda가 Bedrock 모델을 호출한다.
6. Bedrock이 요약 결과를 반환한다.
7. Lambda가 결과를 검증하고 응답한다.
8. 프론트엔드가 요약 결과를 화면에 표시한다.

이 구조는 서버를 직접 운영하지 않아도 된다는 장점이 있다.

EC2 서버를 만들고, 런타임을 설치하고, 배포 스크립트를 만들고, 서버 장애를 직접 처리하지 않아도 된다.
Lambda와 API Gateway를 사용하면 작은 AI 기능을 빠르게 API 형태로 만들 수 있다.

다만 모든 AI 기능을 Lambda로 처리하는 것이 정답은 아니다.
작업 시간이 길거나, 대량 문서 처리처럼 무거운 작업은 별도 Worker나 컨테이너 기반 구조가 더 적합할 수 있다.

이 장에서는 먼저 가장 기본적인 서버리스 구조를 이해하고, 뒤에서 확장 방식도 함께 살펴본다.

3. Amazon Bedrock이란 무엇인가

Amazon Bedrock은 AWS에서 제공하는 관리형 생성형 AI 서비스다.

쉽게 말하면 AWS 안에서 여러 AI 모델을 API로 호출할 수 있게 해주는 서비스다.

개발자는 모델 서버를 직접 운영하지 않고, Bedrock API를 통해 텍스트 생성, 요약, 분류, 임베딩 같은 기능을 사용할 수 있다.

흐름은 다음과 같다.

우리 백엔드
→ Amazon Bedrock API 호출
→ 선택한 AI 모델 실행
→ 응답 반환

Bedrock을 사용하면 다음과 같은 장점이 있다.

- 모델을 직접 설치하지 않아도 된다.
- AWS IAM으로 접근 권한을 제어할 수 있다.
- AWS 안의 다른 서비스와 연동하기 쉽다.
- 여러 모델을 같은 방식으로 사용할 수 있다.
- 기업 환경에서 보안과 운영 관리를 AWS 체계 안에서 설계할 수 있다.

예를 들어 고객 문의 요약 기능에서는 Bedrock에 다음과 같은 요청을 보낼 수 있다.

역할:
너는 고객센터 상담 내용을 요약하는 도우미다.

요청:
아래 고객 문의를 3문장 이내로 요약해줘.

조건:
- 개인정보는 포함하지 않는다.
- 추정하지 않는다.
- 고객이 겪는 문제를 먼저 작성한다.

고객 문의:
하트를 충전했는데 반영이 안 됩니다.

Bedrock은 선택한 모델을 사용해 요약 결과를 반환한다.

사용자는 하트를 충전했지만 서비스에 반영되지 않았다고 문의했다.
결제 또는 충전 처리 상태 확인이 필요하다.
개인 결제 정보는 별도로 확인해야 한다.

개발자는 이 결과를 관리자 화면에 표시하거나 DB에 저장할 수 있다.

Amazon Bedrock은 AWS에서 여러 생성형 AI 모델을 API로 사용할 수 있게 해주는 관리형 서비스다.
모델 서버를 직접 운영하지 않고도 텍스트 생성, 요약, 분류, 임베딩 같은 기능을 만들 수 있다.

4. Bedrock을 사용할 때의 기본 흐름

Bedrock을 사용한 AI 기능의 기본 흐름은 다음과 같다.

1. 사용자 요청을 받는다.
2. 백엔드에서 입력값을 검증한다.
3. 필요한 경우 개인정보를 마스킹한다.
4. 프롬프트를 구성한다.
5. Bedrock 모델을 호출한다.
6. 응답을 검증한다.
7. 결과를 사용자에게 반환하거나 저장한다.
8. 로그와 사용량을 기록한다.

코드 흐름으로 보면 다음과 비슷하다.

async function summarizeInquiry(inquiryText) {
    const maskedText = maskPersonalInfo(inquiryText);

    const prompt = `
너는 고객 문의를 요약하는 상담 지원 도구다.

아래 고객 문의를 3문장 이내로 요약해라.

조건:
- 개인정보는 포함하지 않는다.
- 추정하지 않는다.
- 고객이 겪는 문제를 먼저 작성한다.

고객 문의:
${maskedText}
`;

    const response = await callBedrockModel({
        modelId: "selected-model",
        prompt,
        maxTokens: 300,
        temperature: 0.2
    });

    return validateSummary(response);
}

여기서 중요한 것은 Bedrock 호출 코드 자체가 아니다.

운영 서비스에서는 Bedrock을 호출하기 전후의 처리가 더 중요하다.

호출 전:
- 사용자 인증
- 권한 확인
- 입력 길이 제한
- 개인정보 마스킹
- 프롬프트 구성
- 모델 선택

호출 후:
- 응답 검증
- 에러 처리
- 비용 추적
- 로그 기록
- 결과 저장 여부 판단

Bedrock은 AI 모델을 실행해주는 역할을 한다.
하지만 “어떤 데이터를 보낼지”, “응답을 어떻게 사용할지”, “실패하면 어떻게 처리할지”는 서비스가 직접 설계해야 한다.

5. Lambda와 AI API 연동

AWS Lambda는 서버를 직접 관리하지 않고 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스다.

AI 기능이 작고 요청 단위로 처리된다면 Lambda는 좋은 선택이 될 수 있다.

예를 들어 다음 기능은 Lambda와 잘 맞는다.

- 고객 문의 1건 요약
- 신고 내용 1건 분류
- 짧은 문장 번역
- 관리자 화면에서 AI 초안 생성
- 간단한 문서 요약

Lambda를 사용하면 다음과 같은 흐름을 만들 수 있다.

API Gateway
→ Lambda 실행
→ Bedrock 호출
→ 결과 반환

Lambda 함수는 요청을 받을 때만 실행된다.
사용량이 적을 때는 비용을 줄일 수 있고, 관리해야 할 서버도 줄어든다.

간단한 예시 구조는 다음과 같다.

export const handler = async (event) => {
    try {
        const body = JSON.parse(event.body || "{}");
        const inquiryText = body.inquiryText;

        if (!inquiryText) {
            return {
                statusCode: 400,
                body: JSON.stringify({
                    message: "문의 내용이 없습니다."
                })
            };
        }

        if (inquiryText.length > 10000) {
            return {
                statusCode: 400,
                body: JSON.stringify({
                    message: "입력 내용이 너무 깁니다."
                })
            };
        }

        const maskedText = maskPersonalInfo(inquiryText);

        const summary = await summarizeWithBedrock(maskedText);

        return {
            statusCode: 200,
            body: JSON.stringify({
                summary
            })
        };
    } catch (error) {
        console.error("AI summary failed", error);

        return {
            statusCode: 500,
            body: JSON.stringify({
                message: "AI 요약을 생성하지 못했습니다."
            })
        };
    }
};

이 예시는 단순하지만 중요한 흐름을 포함한다.

- 요청 body 파싱
- 필수 입력 확인
- 입력 길이 제한
- 개인정보 마스킹
- Bedrock 호출
- 에러 처리
- 사용자용 오류 메시지 반환

Lambda를 사용할 때 주의할 점도 있다.

- 실행 시간 제한이 있다.
- 긴 AI 응답이나 대량 작업에는 부적합할 수 있다.
- 외부 API 호출 시간이 길어지면 timeout이 발생할 수 있다.
- 동시 요청이 많으면 동시성 제한을 고려해야 한다.
- VPC 안에서 실행하면 네트워크 구성이 복잡해질 수 있다.

즉, Lambda는 짧고 명확한 AI 작업에는 좋지만, 대량 처리나 장시간 작업에는 다른 구조를 고려해야 한다.

6. API Gateway로 AI 기능 제공하기

API Gateway는 외부 요청을 받아 Lambda나 다른 백엔드로 연결해주는 서비스다.

AI 기능을 API로 제공하려면 API Gateway를 사용할 수 있다.

예를 들어 고객 문의 요약 API를 만든다고 해보자.

POST /ai/inquiry-summary

프론트엔드는 이 API를 호출한다.

{
  "inquiryText": "하트를 충전했는데 반영이 안 됩니다."
}

API Gateway는 요청을 Lambda로 전달한다.

Lambda는 Bedrock을 호출하고 결과를 반환한다.

{
  "summary": "사용자는 하트를 충전했지만 서비스에 반영되지 않았다고 문의했습니다."
}

API Gateway를 사용하면 다음을 처리할 수 있다.

- API 엔드포인트 제공
- 인증 연동
- 요청 크기 제한
- Rate Limit
- CORS 설정
- API 호출 로그
- 스테이지 관리

AI 기능에서는 Rate Limit이 특히 중요하다.

AI API는 요청이 많아질수록 비용이 증가한다.
따라서 API Gateway 또는 백엔드에서 요청 제한을 걸어야 한다.

예를 들어 다음과 같은 정책을 둘 수 있다.

- 사용자 1명당 분당 10회 요청
- 관리자 기능은 IP 또는 계정 기준 제한
- 비정상적으로 긴 요청 차단
- 특정 API는 내부망에서만 접근 가능

API Gateway는 외부 요청의 입구다.
AI 기능을 공개 API처럼 제공할 때는 반드시 인증, 권한, 요청 제한을 함께 설계해야 한다.

7. S3 문서 저장소 구성

RAG나 문서 요약 기능을 만들려면 문서를 저장할 공간이 필요하다.

AWS에서는 Amazon S3를 문서 저장소로 사용할 수 있다.

S3는 파일을 객체 형태로 저장하는 서비스다.

예를 들어 다음과 같은 문서를 저장할 수 있다.

- 사내 운영 매뉴얼
- 고객센터 응대 가이드
- 개발 문서
- API 명세서
- 정책 문서
- 장애 대응 문서
- PDF, Markdown, HTML 파일

문서 기반 AI 기능의 기본 흐름은 다음과 같다.

문서 업로드
→ S3 저장
→ 문서 파싱
→ 문서 분할
→ 임베딩 생성
→ 검색 인덱스 저장
→ 질문 시 관련 문서 검색
→ Bedrock으로 답변 생성

S3에 문서를 저장할 때는 파일만 넣는 것으로 끝나지 않는다.

문서 메타데이터도 함께 관리해야 한다.

- 문서 제목
- 문서 유형
- 작성자
- 소유 부서
- 생성일
- 수정일
- 버전
- 접근 권한
- 만료 여부

예를 들어 S3 경로를 다음처럼 구성할 수 있다.

s3://company-ai-docs/
  customer-center/
    refund-policy.md
    charge-guide.pdf

  development/
    api-guide.md
    deploy-manual.md

  operation/
    incident-response.md
    monitoring-guide.md

하지만 경로만으로 권한을 판단하면 부족할 수 있다.

문서별로 접근 권한을 별도 메타데이터로 관리하는 것이 좋다.

{
  "documentId": "doc_123",
  "title": "환불 정책",
  "department": "customer-center",
  "owner": "CS팀",
  "allowedRoles": [
    "cs_manager",
    "admin"
  ],
  "updatedAt": "2026-05-04"
}

RAG에서는 사용자가 질문했을 때 모든 문서를 검색하면 안 된다.
사용자가 볼 수 있는 문서만 검색해야 한다.

사용자 질문
→ 사용자 권한 확인
→ 권한 있는 문서만 검색
→ 관련 문서 추출
→ Bedrock으로 답변 생성

S3는 문서 저장소 역할을 할 수 있지만, 권한과 메타데이터 설계는 애플리케이션에서 함께 처리해야 한다.

8. 문서 업로드와 색인 처리

S3에 문서를 저장한 뒤에는 AI가 검색할 수 있는 형태로 가공해야 한다.

문서를 그대로 S3에 넣었다고 해서 AI가 자동으로 내용을 이해하는 것은 아니다.

RAG를 만들려면 보통 다음 작업이 필요하다.

1. 문서 업로드
2. 문서 텍스트 추출
3. 문서 정제
4. chunk 단위로 분할
5. 임베딩 생성
6. 벡터DB 또는 검색 인덱스에 저장

예를 들어 운영 매뉴얼 PDF를 업로드했다고 해보자.

incident-response.pdf

이 문서를 검색 가능한 형태로 만들려면 먼저 텍스트를 추출해야 한다.

그 다음 적절한 크기로 나눈다.

chunk 1:
장애 등급 정의

chunk 2:
장애 발생 시 초기 대응 절차

chunk 3:
담당자 연락 체계

chunk 4:
장애 보고서 작성 기준

각 chunk에 임베딩을 생성하고 검색 인덱스에 저장한다.

{
  "chunkId": "chunk_001",
  "documentId": "incident-response",
  "title": "장애 대응 매뉴얼",
  "content": "장애 등급은 서비스 영향도에 따라...",
  "embedding": [
    0.012,
    -0.031,
    0.221
  ],
  "metadata": {
    "department": "operation",
    "allowedRoles": [
      "devops",
      "admin"
    ],
    "updatedAt": "2026-05-04"
  }
}

이제 사용자가 질문하면 관련 chunk를 검색할 수 있다.

질문:
장애 발생 시 최초 보고는 누구에게 해야 해?

검색 결과:
장애 대응 매뉴얼 chunk 3

AI 답변:
장애 발생 시 최초 보고는 운영 담당자와 개발 리더에게 전달해야 합니다...

AWS에서는 이런 색인 처리를 Lambda, Step Functions, ECS, Batch 같은 서비스로 구성할 수 있다.

단순한 문서 업로드라면 Lambda로 처리할 수 있다.
문서가 크거나 처리 시간이 길다면 Step Functions나 ECS Worker를 고려할 수 있다.

작은 문서:
S3 업로드 이벤트
→ Lambda 실행
→ 텍스트 추출
→ 임베딩 생성
→ 저장

큰 문서 또는 대량 문서:
S3 업로드
→ Queue 등록
→ Worker 처리
→ 색인 결과 저장

문서 색인은 한 번 만들고 끝나는 작업이 아니다.
문서가 수정되면 다시 색인해야 하고, 삭제되면 검색 인덱스에서도 제거해야 한다.

따라서 문서 기반 AI를 만들 때는 “문서를 어떻게 검색할 것인가”뿐 아니라 “문서 변경을 어떻게 반영할 것인가”도 함께 설계해야 한다.

9. Bedrock 기반 RAG 구성 개요

AWS 기반으로 RAG를 구성하면 대략 다음과 같은 구조가 된다.

[문서 등록 흐름]

문서 업로드
→ S3 저장
→ 문서 텍스트 추출
→ chunk 분할
→ 임베딩 생성
→ 벡터 검색 저장소에 저장

[질문 답변 흐름]

사용자 질문
→ 사용자 권한 확인
→ 질문 임베딩 생성
→ 관련 chunk 검색
→ 프롬프트 구성
→ Bedrock LLM 호출
→ 답변 생성
→ 출처 포함 응답

여기서 Bedrock은 두 가지 역할로 사용될 수 있다.

1. 임베딩 생성
2. 답변 생성

임베딩은 문장이나 문서를 숫자 벡터로 바꾸는 과정이다.
질문과 문서를 같은 벡터 공간에 넣으면 의미가 비슷한 문서를 검색할 수 있다.

답변 생성은 검색된 문서를 바탕으로 사용자에게 자연어 답변을 만드는 과정이다.

예를 들어 사용자가 이렇게 질문했다고 하자.

충전 후 하트가 반영되지 않았을 때 고객센터는 어떻게 안내해야 해?

RAG 시스템은 먼저 관련 문서를 찾는다.

검색된 문서:
- 충전 장애 응대 가이드
- 결제 승인 후 미반영 처리 절차
- 환불 요청 기준

그 다음 Bedrock 모델에 다음처럼 전달한다.

너는 고객센터 상담원을 돕는 AI다.
아래 참고 문서를 근거로 질문에 답해라.
문서에 없는 내용은 추정하지 말고 모른다고 답해라.
답변에는 참고한 문서 제목을 포함해라.

질문:
충전 후 하트가 반영되지 않았을 때 고객센터는 어떻게 안내해야 해?

참고 문서:
[문서 1] 충전 장애 응대 가이드
...

[문서 2] 결제 승인 후 미반영 처리 절차
...

AI는 문서 기반으로 답변한다.

충전 후 하트가 반영되지 않은 경우 먼저 결제 승인 여부와 충전 내역 반영 상태를 확인해야 합니다.
승인 문자는 받았지만 서비스 내 반영이 되지 않았다면 결제 승인 후 미반영 처리 절차에 따라 담당 부서 확인이 필요합니다.

참고 문서:
- 충전 장애 응대 가이드
- 결제 승인 후 미반영 처리 절차

RAG에서 중요한 것은 모델이 아니라 전체 흐름이다.

- 문서가 최신인가?
- 문서가 잘 분할되었는가?
- 검색 결과가 질문과 관련 있는가?
- 사용자가 볼 수 있는 문서만 검색했는가?
- AI가 문서에 없는 내용을 지어내지 않는가?
- 출처를 표시하는가?

Bedrock은 RAG의 모델 부분을 담당할 수 있다.
하지만 문서 품질, 검색 품질, 권한 필터, 출처 표시는 애플리케이션 설계가 중요하다.

10. CloudWatch로 로그 관리하기

AI 기능을 운영하려면 로그와 모니터링이 필요하다.

AWS에서는 CloudWatch를 사용해 Lambda 로그, API Gateway 로그, 애플리케이션 지표를 확인할 수 있다.

AI 기능에서 남기면 좋은 로그는 다음과 같다.

- 요청 ID
- 사용자 ID 또는 관리자 ID
- 기능명
- 모델명
- 입력 길이
- 출력 길이
- 응답 시간
- 성공/실패 여부
- 에러 코드
- 재시도 여부

예를 들어 Lambda에서 다음처럼 로그를 남길 수 있다.

{
  "requestId": "ai_req_20260504_001",
  "feature": "inquiry_summary",
  "model": "bedrock-model",
  "inputLength": 2400,
  "outputLength": 380,
  "latencyMs": 3200,
  "status": "success"
}

이 로그를 CloudWatch에서 확인하면 다음을 분석할 수 있다.

- 어떤 기능이 자주 호출되는가?
- 평균 응답 시간이 얼마나 되는가?
- 실패율이 높아지는 시점이 있는가?
- 특정 모델에서 오류가 많이 발생하는가?
- 입력 길이가 비정상적으로 긴 요청이 있는가?

다만 AI 로그를 남길 때는 주의해야 한다.

AI 입력에는 개인정보나 내부 정보가 포함될 수 있다.
따라서 원문 전체를 그대로 로그에 남기는 것은 위험하다.

좋은 로그 정책은 다음과 같다.

- 원문 입력은 기본적으로 저장하지 않는다.
- 필요한 경우 마스킹 후 저장한다.
- 토큰 수, 길이, 모델명, 응답 시간 같은 메타데이터 중심으로 남긴다.
- 디버깅용 상세 로그는 짧은 기간만 보관한다.
- 민감 정보 접근 로그는 별도로 관리한다.

CloudWatch는 운영에 필요한 정보를 제공하지만, 로그에 무엇을 남길지는 개발팀이 신중하게 결정해야 한다.

11. CloudWatch 지표와 알림

로그만 남기는 것으로는 부족하다.

운영 서비스에서는 이상 상황을 빠르게 감지해야 한다.

AI 기능에서는 다음 지표를 모니터링하면 좋다.

예를 들어 다음 상황에서는 알림이 필요하다.

- 5분 동안 AI 요청 실패율이 20%를 넘음
- 평균 응답 시간이 평소보다 3배 증가
- 특정 기능의 요청 수가 갑자기 급증
- timeout이 지속적으로 발생
- 월 예산의 80%를 초과

CloudWatch Alarm을 사용하면 특정 조건에서 알림을 보낼 수 있다.

AI 요청 실패율 증가
→ CloudWatch Alarm 발생
→ SNS 또는 Slack 알림
→ 담당자 확인

AI 기능은 일반 API보다 응답 시간이 길고 외부 모델에 의존한다.
따라서 장애를 빨리 감지할 수 있는 모니터링이 중요하다.

12. IAM으로 권한 관리하기

AWS에서 보안의 기본은 IAM이다.

IAM은 Identity and Access Management의 약자다.
쉽게 말하면 “누가 어떤 AWS 리소스에 접근할 수 있는지”를 정하는 권한 관리 서비스다.

AI 서비스 구성에서도 IAM은 매우 중요하다.

예를 들어 Lambda가 Bedrock을 호출하려면 해당 권한이 필요하다.

Lambda 실행 역할
→ Bedrock 모델 호출 권한

Lambda가 S3에서 문서를 읽어야 한다면 S3 읽기 권한도 필요하다.

Lambda 실행 역할
→ 특정 S3 버킷 읽기 권한

CloudWatch에 로그를 남기려면 로그 쓰기 권한도 필요하다.

Lambda 실행 역할
→ CloudWatch Logs 쓰기 권한

중요한 원칙은 최소 권한이다.

최소 권한은 필요한 작업을 수행할 수 있을 만큼만 권한을 부여하는 원칙이다.
모든 권한을 열어두면 실수나 보안 사고가 발생했을 때 피해 범위가 커진다.

나쁜 예시는 다음과 같다.

Lambda에 모든 S3 버킷 접근 권한 부여
Lambda에 모든 Bedrock 모델 호출 권한 부여
관리자 권한을 서비스 코드에 부여

좋은 예시는 다음과 같다.

Lambda는 특정 S3 버킷의 특정 경로만 읽을 수 있음
Lambda는 필요한 Bedrock 모델만 호출할 수 있음
문서 색인 Lambda와 답변 생성 Lambda의 권한을 분리함
운영자와 개발자의 콘솔 권한을 분리함

AI 기능에서는 IAM뿐 아니라 애플리케이션 권한도 함께 필요하다.

IAM은 AWS 리소스 접근 권한을 제어한다.
하지만 “사용자 A가 문서 B를 볼 수 있는가?” 같은 서비스 내부 권한은 애플리케이션이 판단해야 한다.

IAM:
Lambda가 S3를 읽을 수 있는가?

애플리케이션 권한:
현재 사용자가 이 문서를 볼 수 있는가?

둘을 혼동하면 안 된다.

13. AWS 기반 AI 구성에서 보안상 주의할 점

AWS를 사용한다고 자동으로 안전해지는 것은 아니다.

AI 기능은 데이터를 다루기 때문에 보안 설계를 신중하게 해야 한다.

먼저 API Key와 비밀값을 코드에 직접 넣으면 안 된다.

// 나쁜 예
const apiKey = "my-secret-key";

비밀값은 환경 변수나 AWS Secrets Manager 같은 비밀 관리 서비스에 저장하는 것이 좋다.

서비스 코드
→ Secrets Manager에서 비밀값 조회
→ 외부 API 호출

Bedrock처럼 IAM 기반으로 호출하는 서비스는 API Key 대신 IAM Role을 사용해 권한을 제어할 수 있다.
이 경우에도 Lambda 실행 역할의 권한을 최소화해야 한다.

두 번째는 S3 문서 접근 권한이다.

문서 기반 AI를 만들 때 S3 버킷을 공개로 열어두면 안 된다.

나쁜 구조:
S3 문서 버킷 공개 접근 허용

좋은 구조:
S3 버킷 비공개
→ Lambda나 백엔드만 접근
→ 사용자 권한에 따라 문서 검색 결과 제한

세 번째는 로그에 민감 정보를 남기지 않는 것이다.

위험한 로그:
- 고객 문의 원문 전체
- 결제 정보
- 인증 토큰
- 내부 API Key
- 관리자 개인정보

네 번째는 네트워크 접근 범위다.

내부 관리자용 AI 기능이라면 외부에 공개할 필요가 없을 수 있다.

- 관리자 인증 필수
- 사내망 또는 VPN 접근 제한
- WAF 적용
- Rate Limit 적용

다섯 번째는 모델 응답을 그대로 신뢰하지 않는 것이다.

AI가 생성한 결과가 실제 작업으로 이어지는 경우에는 승인 단계가 필요하다.

AI가 보고서 초안 생성
→ 담당자 검토
→ 최종 저장

또는

AI가 Jira 이슈 생성 제안
→ 사용자가 확인
→ 승인 후 생성

AI 서비스의 보안은 AWS 설정과 애플리케이션 로직이 함께 맞물려야 한다.

14. 간단한 AWS AI 아키텍처 예시: 고객 문의 요약

이제 실제 예시를 하나 구성해보자.

목표는 고객 문의 요약 기능이다.

관리자가 고객 문의 상세 페이지에서 "AI 요약" 버튼을 누르면,
AI가 문의 내용을 3문장 이내로 요약해준다.

기본 구성은 다음과 같다.

관리자 브라우저
→ API Gateway
→ Lambda
→ Bedrock
→ Lambda
→ API Gateway
→ 관리자 브라우저

처리 흐름은 다음과 같다.

1. 관리자가 요약 버튼을 클릭한다.
2. 프론트엔드가 문의 ID를 포함해 API를 호출한다.
3. API Gateway가 요청을 Lambda로 전달한다.
4. Lambda가 관리자 인증 정보를 확인한다.
5. Lambda가 문의 내용을 DB에서 조회한다.
6. 개인정보를 마스킹한다.
7. 요약 프롬프트를 구성한다.
8. Bedrock 모델을 호출한다.
9. 응답을 검증한다.
10. 요약 결과를 반환한다.
11. 요청 ID, 기능명, 응답 시간, 성공 여부를 로그로 남긴다.

여기서 중요한 보안 포인트는 다음과 같다.

- 관리자가 해당 문의를 볼 수 있는지 확인해야 한다.
- 문의 원문을 그대로 로그에 남기면 안 된다.
- 개인정보는 가능하면 마스킹 후 AI에 전달한다.
- AI 응답은 상담원 보조용 초안으로 표시한다.

비용 제한도 필요하다.

- 관리자 1명당 하루 요청 횟수 제한
- 문의 1건당 중복 요약 요청 방지
- 너무 긴 문의는 일부만 요약하거나 별도 처리
- 월 사용량 모니터링

이 기능은 처음 AI를 도입하기에 적합하다.

이유는 다음과 같다.

- 사용자에게 직접 노출되지 않는다.
- 상담원이 검토할 수 있다.
- 업무 효율 개선 효과를 확인하기 쉽다.
- 실패해도 기존 업무 흐름이 유지된다.

처음 AI 기능을 운영에 붙일 때는 이런 관리자 보조 기능부터 시작하는 것이 안전하다.

15. 간단한 AWS AI 아키텍처 예시: 문서 검색 챗봇

이번에는 사내 문서 검색 챗봇을 생각해보자.

목표는 다음과 같다.

직원이 사내 운영 매뉴얼이나 개발 문서에 대해 질문하면,
AI가 관련 문서를 찾아 답변하고 출처를 함께 보여준다.

구조는 고객 문의 요약보다 조금 더 복잡하다.

[문서 등록]
문서 업로드
→ S3 저장
→ 문서 파싱
→ chunk 분할
→ 임베딩 생성
→ 벡터 검색 저장소 저장

[질문 답변]
사용자 질문
→ API Gateway
→ Lambda 또는 백엔드
→ 사용자 권한 확인
→ 관련 문서 검색
→ Bedrock 호출
→ 답변 생성
→ 출처 포함 응답

이 구조에서 S3는 원본 문서 저장소 역할을 한다.

Bedrock은 임베딩 생성과 답변 생성에 사용할 수 있다.

벡터 검색 저장소는 검색을 담당한다.
AWS 안에서는 OpenSearch, Aurora PostgreSQL with pgvector, 또는 별도 벡터DB를 사용할 수 있다.

문서 검색 챗봇에서 가장 중요한 것은 권한이다.

예를 들어 개발팀 문서와 인사팀 문서가 모두 S3에 있다고 해보자.

개발팀 사용자:
개발 문서 검색 가능
인사팀 제한 문서 검색 불가

인사팀 사용자:
인사 문서 검색 가능
개발팀 비공개 문서 검색 불가

질문을 받은 뒤 전체 문서를 검색하면 안 된다.

반드시 사용자의 권한을 먼저 확인하고, 권한 있는 문서만 검색해야 한다.

사용자 질문
→ 사용자 부서와 역할 확인
→ allowedRoles 필터 적용
→ 관련 chunk 검색
→ 답변 생성

또한 답변에는 출처를 표시해야 한다.

답변:
장애 발생 시 최초 보고는 운영 담당자와 개발 리더에게 전달해야 합니다.

출처:
- 장애 대응 매뉴얼 > 초기 대응 절차

출처가 있어야 사용자가 답변을 검증할 수 있다. AI 답변은 그럴듯할 수 있지만, 실제 업무에서는 근거 문서를 확인할 수 있어야 한다.

16. Lambda만으로 부족한 경우

간단한 AI 기능은 Lambda로 충분할 수 있다.

하지만 모든 AI 작업을 Lambda로 처리하는 것은 적절하지 않을 수 있다.

다음 작업은 Lambda만으로 부족할 수 있다.

- 대량 문서 색인
- 수백 페이지 PDF 처리
- 대량 고객 문의 분류
- 긴 로그 분석
- 장시간 실행되는 배치 작업
- 복잡한 RAG 파이프라인

이런 작업은 시간이 오래 걸리고, 실패 시 재처리도 필요하다.

이 경우에는 비동기 구조를 고려해야 한다.

예를 들어 대량 문서 색인은 다음처럼 구성할 수 있다.

문서 업로드
→ S3 이벤트 발생
→ SQS에 작업 등록
→ Worker가 문서 처리
→ 임베딩 생성
→ 검색 인덱스 저장
→ 처리 결과 기록

여기서 Worker는 Lambda일 수도 있고, ECS나 EKS에서 실행되는 컨테이너일 수도 있다.

작업 흐름이 여러 단계라면 Step Functions를 사용할 수도 있다.

문서 파싱
→ chunk 분할
→ 임베딩 생성
→ 저장
→ 결과 검증

각 단계가 실패하면 어디서 실패했는지 확인하고 재시도할 수 있다.

즉, AWS 기반 AI 서비스는 기능의 성격에 따라 구조를 다르게 잡아야 한다.

처음에는 단순하게 시작하되, 작업 시간이 길어지고 요청량이 늘어나면 비동기 구조로 확장해야 한다.

17. AWS 기반 AI 서비스의 비용 고려

AWS 기반 AI 서비스도 비용 구조를 이해해야 한다.

AI 기능 하나를 만들더라도 여러 서비스 비용이 함께 발생할 수 있다.

- Bedrock 모델 호출 비용
- Lambda 실행 비용
- API Gateway 호출 비용
- S3 저장 비용
- 문서 처리 Worker 비용
- 벡터DB 또는 OpenSearch 비용
- CloudWatch 로그 저장 비용
- 데이터 전송 비용

처음에는 Bedrock 비용만 생각하기 쉽다.

하지만 RAG를 만들면 주변 서비스 비용도 함께 발생한다.

예를 들어 문서 검색 챗봇은 다음 비용이 생길 수 있다.

문서 저장:
S3 비용

문서 색인:
Lambda 또는 Worker 실행 비용
임베딩 생성 비용

검색:
벡터DB 또는 OpenSearch 비용

답변 생성:
Bedrock LLM 호출 비용

로그:
CloudWatch 저장 비용

비용을 줄이려면 다음을 고려해야 한다.

- 짧은 질문에는 저렴한 모델 사용
- 긴 문서는 필요한 chunk만 전달
- 중복 질문 캐싱
- 문서 재색인 주기 조절
- CloudWatch 로그 보관 기간 설정
- 기능별 사용량 제한
- 관리자 화면에서 요청 횟수 제한

예를 들어 RAG에서 검색된 문서를 너무 많이 AI에게 전달하면 입력 토큰이 증가한다.

검색 결과 20개 chunk 전달:
입력 토큰 증가
→ 비용 증가
→ 응답 속도 저하

검색 결과 3~5개 chunk 전달:
비용 절감
→ 응답 속도 개선
→ 관련성 높은 문서만 사용

AI 서비스 비용은 모델 비용만 보지 말고 전체 아키텍처 비용으로 봐야 한다.

18. AWS 기반 AI 서비스의 운영 체크리스트

AWS 위에서 AI 기능을 운영하려면 다음 항목을 점검해야 한다.

이 체크리스트는 AWS에만 해당하는 것은 아니다. 하지만 AWS 기반으로 구성할 때는 각 항목을 어떤 서비스로 처리할지 명확히 정해야 한다.

예를 들어 다음처럼 매핑할 수 있다.

중요한 것은 AWS 서비스를 많이 쓰는 것이 아니다.
필요한 요구사항을 안전하고 단순한 구조로 만족시키는 것이다.

19. 처음 AWS AI 기능을 만들 때 추천하는 순서

처음부터 복잡한 RAG 시스템이나 AI 업무 자동화를 만들려고 하면 어렵다.

AWS에서 AI 기능을 처음 만든다면 다음 순서를 추천한다.

1. 관리자용 단순 요약 기능 만들기
2. Bedrock 호출 구조 만들기
3. API Gateway + Lambda로 API 제공하기
4. CloudWatch로 로그 확인하기
5. 사용량과 응답 시간 기록하기
6. 개인정보 마스킹 추가하기
7. 에러 처리와 timeout 처리하기
8. 기능별 프롬프트 템플릿 분리하기
9. 문서 기반 RAG로 확장하기
10. 비동기 문서 색인 구조 추가하기

첫 기능은 사용자에게 직접 노출되는 것보다 관리자 보조 기능이 좋다.

예를 들어 다음 기능이 적합하다.

- 고객 문의 요약
- 신고 내용 요약
- 운영 로그 요약
- 장애 보고서 초안
- 공지사항 초안 작성

이런 기능은 AI가 틀려도 사람이 검토할 수 있다.
실패해도 기존 업무가 완전히 멈추지 않는다.

이 단계에서 중요한 것은 AI 기능의 효과를 확인하는 것이다.

- 실제 업무 시간이 줄어드는가?
- 사용자가 계속 사용하는가?
- AI 답변을 얼마나 수정해야 하는가?
- 비용은 감당 가능한가?
- 응답 속도는 충분한가?
- 보안상 문제가 없는가?

효과가 확인되면 그다음 RAG, 자동화, 에이전트 구조로 확장하는 것이 좋다.

20. 정리

AWS 기반 AI 서비스는 여러 AWS 서비스를 조합해 AI 기능을 운영 환경에 올리는 방식이다.

가장 기본적인 구조는 API Gateway, Lambda, Amazon Bedrock을 연결하는 것이다.

프론트엔드
→ API Gateway
→ Lambda
→ Bedrock
→ Lambda
→ 프론트엔드

여기에 문서 기반 AI를 만들려면 S3 문서 저장소, 문서 파싱, 임베딩, 벡터 검색, 권한 필터, 출처 표시가 추가된다.

Bedrock은 AI 모델을 직접 운영하지 않고 API로 사용할 수 있게 해준다.
Lambda는 짧은 AI 작업을 서버리스로 처리하는 데 적합하다.
API Gateway는 AI 기능을 API로 제공하는 입구 역할을 한다.
S3는 문서 저장소로 사용할 수 있고, CloudWatch는 로그와 모니터링을 담당한다.
IAM은 각 서비스가 필요한 작업만 수행하도록 권한을 제한한다.

하지만 AWS 서비스를 연결했다고 해서 자동으로 안전한 AI 서비스가 되는 것은 아니다.

운영 서비스에서는 다음을 반드시 함께 설계해야 한다.

- 인증
- 권한
- 개인정보 마스킹
- 입력 검증
- 응답 검증
- 비용 추적
- 로그 정책
- 장애 대응
- 문서 권한 필터
- 출처 표시

이 장에서 기억해야 할 핵심은 하나다.

AWS 기반 AI 서비스는 Bedrock 하나만 호출하는 구조가 아니다.
API, 서버리스 처리, 문서 저장소, 로그, 권한, 비용 관리가 함께 설계되어야 운영 가능한 AI 서비스가 된다.

17장 핵심 요약